So, I finally merged the
input-hotplug
branches on master. Basically, this means that instead of attempting to hide
behind one device (/dev/input/mice, the console keyboard), and hacking around
it with gash and tape when we actually expose multiple devices[0], we finally
expose multiple devices in a useful way. This is consistent through out the
Xorg and KDrive servers; Xnest and Xvfb also have support, but that's not
the most useful thing ever.
This required a huge overhaul of the old input code, much of which dates back
to the mid-80s; the bits that don't were sticky-taped on the side, working
more in spite of our core input code than with it. So, in addition to being
generally useful and providing things like multiple keymaps on different
keyboards and different acceleration (and so) on different pointer devices,
it also actually caused a net removal of code.
So, once you've set yourself using evdev for the drivers, you can also now
dynamically add and remove devices. Last night, not long before I released
all the components, I removed all the input devices from my configuration
file, told X not to add any, and added 'respeclaration --daemon' to my
session: completely dynamic input. I've been using the core bits (the whole
input API rework) for quite a long time, along with Zepheniah's evdev driver,
but this is the first time I've been using a session with completely hotplugged
input, as opposed to adding and removing devices every now and then to test
the hotplug capabilities, which was actually a piece of cake, compared to
reworking all our core input code to deal with devices appearing and
disappearing.
Still, this all needs good desktop integration. Keyboard and mouse applets
need to become aware of multiple devices[1], and allow people to configure
them separately. The desktop should also take over the role currently
filled by
respeclaration,
which works perfectly well, but shouldn't be generally deployed; management of
input devices thus turns into a session management issue, which leaves the
desktop to dictate policy.
There are still some nits in the D-BUS policy to sort out (right now, only
root can reconfigure the devices), but I believe it's fundamentally the
right model: it's machine-oriented, rather than session-oriented. There are
still some minor changes that need to be made, but working out who should be
trusted to add input devices was more or less impossible in the X security
model.
xserver 1.3 (for Xorg 7.3)
should
be
good
fun.
[0]: Key presses/releases from your second device will just magically appear
from your first device. Useful, huh?
[1]: In brief: check for inputproto 1.4 at build time, check DEVICE_CORE on
whatever appears as the core pointer, and if 'iscore' is 1, then you
have a virtual core pointer. Anything that sets status to 1 for
DEVICE_CORE will also generate core events. Setting controls on the
core keyboard or pointer will propagate those changes down to all
the devices which also send core events. I'm going to document this
soon.
< eikke> is there any "small" thing which I could be able to do, now?